@scottalanmiller I realise this is an old topic, but I've been fighting something similar all day. As it turns out, the implementation of PTY (and also TTY) has changed in recent versions of OpenSSH for windows. When the SSH session is built from within a script, the new OpenSSH implementation detects that the session is not setup from an interactive terminal, and therefore does not assign a PTY to the session, which results in the unability of the Get-Command command to send its output to STDOUT, hence the access denied error. Solution is (at least in the situation I am in) to use the -t (or even -tt) flag with the ssh command to set up the session

@dave247 said in Most of my Windows 10 1803 computers upgraded to 1809 despite it not being approved in WSUS / Dual Scan is a thing:

@scottalanmiller said in Most of my Windows 10 1803 computers upgraded to 1809 despite it not being approved in WSUS / Dual Scan is a thing:

@dave247 said in Most of my Windows 10 1803 computers upgraded to 1809 despite it not being approved in WSUS / Dual Scan is a thing:

@dbeato said in Most of my Windows 10 1803 computers upgraded to 1809 despite it not being approved in WSUS / Dual Scan is a thing:

@dave247 said in Most of my Windows 10 1803 computers upgraded to 1809 despite it not being approved in WSUS / Dual Scan is a thing:

e systems was a consumer version of Windows 10 which the previous tech installed - no idea where he got it.

Probably came pre-installed on the Dell Computer and not imaged.

Actually it had Windows 7 installed on it but then the co-worker put his version of Windows 10 that I think he got from college on it, and a few other systems. So idk.

Windows 10 will activate on a Windows 7 license. So should be all set from that perspective.

I don't think so.. and it was a fresh install, or at least I know he used the Windows 10 key that he had been provided. That key was also used on about 5 other systems at the time.

You can work around it, but should accept the Win 7 key, too.